Tools for purchasing transactions

ABSTRACT

Financing tools can provide a flexible credit services to customer. A credit service provider can collect personal data from clients that can include a mobile telephone number and a legal name of the client as well as purchase information from a merchant. Based upon the collected data, the system can determine a client credit risk. The system can make a credit decision to offer a client credit to purchase goods or services based upon the credit risk.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent ApplicationNo. 61/992,984, “Tools For Purchasing Transactions” filed May 14, 2015and U.S. Provisional Patent Application No. 62/048,186, “Tools ForPurchasing Transactions” filed Sep. 9, 2015 which are both herebyincorporated by reference in their entirties.

BACKGROUND

When purchases are made by customers from merchants, the typicaltransaction involves selecting the goods or services and paying for themwith traditional means such as cash, checks, credit cards or debitcards. These traditional means are not adjustable and if credit cardsare used, a very high fixed interest rate can be charged. Thus, there isvery little flexibility available when the customer needs purchasingcredit. What is needed is a system that provides an improved system andmethod for providing purchasing credit for customers to purchase goodsand services from merchants.

SUMMARY OF THE INVENTION

The present invention provides a flexible system and method forproviding financing tools to customers and merchants. The system caninitiate a credit process and proceed to collect data from the customersuch as mobile phone number, full legal name, email address, birthday,at least a portion of the social security number, etc. The system canthen collect data from the merchant such as: merchant identification,items being purchased, etc. The system can also collect data from thecredit provider.

The credit being provided can be customized for the customer, merchantand credit provider in various different ways. For example, differenttypes of offered financing terms can include: the amount of credit beingoffered to the customer, the financing terms (duration, number ofpayments, payment dates, interest, etc.), group offers, merchantsubsidies, etc. In different embodiments, customers and/or merchants canuse tools to provide various types of credit at any time before, duringor after a purchasing transaction. Customers with higher estimatedcredit determinations or creditworthiness can be given better financingterms including: higher total credit, extended duration of payments,extended number of payments, flexible payment dates and lower interestrates than customers with lower estimated credit determinations.

In different embodiments, the system can provide a loan for a purchasebased upon a minimal amount of user information such as a name and amobile phone number. However, in some embodiments, the system may notprovide a sufficient loan to cover the entire cost of the desiredpurchase. In traditional purchasing systems, such as credit cards, thetransaction would simply be cancelled and the user would have to find analternative means for paying for the entire purchase or not make thepurchase at all. In contrast, the inventive system can allow for a userto make a purchase based upon a partial loan for the purchase. Forexample, if the total purchase is for $1,000 and the maximum loan creditallowed by the system is $600, the system will allow the user to providea $400 down payment to immediately complete the purchase.

The down payment can be provided through various means. For example, thedown payment could be provided in cash, for example cash paid at a storefor an online transaction by the user. Alternatively, the down paymentcan be money from a bank account, a debit card, a prepaid card, a giftcard, a credit card, a business line of credit, a return store credit, abarter transaction, or any other monetary source.

In some embodiments, the system can further adjust the loan terms basedupon increasing the down payment or by submitting additional informationabout the user. For example, the system user interface can display aninitial set of loan terms that include a loan amount, interest andrepayment information. The user interface can also include buttons foradding more money to the down payment and/or adding more informationabout the user. If the user decides to add more down payment money tothe purchase the system can improve the loan terms for example byreducing the loan interest rate or increasing the loan repaymentduration. If the user decides to add more information, the system cananalyze the user information and make some predictions about the creditworthiness of the user. The additional user information can include:bank account, social network, home phone number, credit card, homeaddress and/or employer information. With this additional user creditinformation, the system can adjust the loan terms which can includechanges to the interest rate, credit loan amount and/or repaymentduration. In some cases the additional user information that can suggestthat the user is not a good credit risk which can result in lessfavorable loan terms.

In various embodiments, the system may have Universal Installments thatprovide a plurality of basic purchasing tools. If a customer is offeredcredit, the customer can select additional custom terms. Theseadditional terms can include: the number of payments, payment dates,payment intervals, financing fees, and scheduling of those payments. Forexample, the payments can be made each month for the next 3 months, orin other embodiments the 3 payments can be made on months 1, 7 and 8.The payments can include traditional fee calculations which can belisted as interest rates or APRs, upfront service fees which can beeither flat fees or fees computed as a percentage of the credit orupfront fees linked to an interest rate calculation, late fees as eithera flat fee or percentage of the credit. The presentation of the feecalculations is designed to make the transaction more transparent to thecustomer, and to help the customer understand the loan terms that theyare signing up for and how much the loan repayment will cost. Thegoodwill among customers from such transparency is anticipated to be anadvantage.

In an embodiment, when a purchase is divided up into multipleinstallments, the interest and fees can be pre-computed at the time ofthe loan. The interest and fees can be added to the principal anddivided into equal monthly payments which can be called the “upfrontinterest calculation.” In another embodiment, the purchase could bedivided into multiple installment payments, and the interest and feescalculated with a daily/monthly compounding period which can be calledthe “iterative interest calculation.” To the user, these calculationsmay appear similar with equal monthly payment and interest rates.However, differences become apparent in the case of early payment andthe interest rebate due to the user in these situations.

In an embodiment, when the system accounting calculations are done, thestatement or credit repayment time length can be variable and does notneed to comply with normal payment schemes. Thus, a 30 day close may notbe necessary. In contrast, a credit card typically requires a set 30 dayclose, and interest is charged on the average balance. To generate acurrent statement for a customer account, the terms of every purchaseand/or transaction can be summed by the system to capture the currentbalance, and future payments and fees and balances can be projected.Additionally, credit statements having similar variable payment timelengths can be set up for any type of transaction such as: groceries,gas, clothing, etc., or from specific merchants such as: Amazon, 1800Flowers, etc., or from sub-accounts such as son and daughtersub-accounts from a parent primary account.

In an embodiment, the back end accounting system for transaction/creditstatements can have specific features. An underlying credit providersystem can manage payment terms for any number of transactions or groupsof transactions in any payment configuration. For example, the systemcan process multiple installments in order to pay for a single purchaseas a group of transactions. The back end can manage interest on the perpurchase level, the per transaction level, and/or the per payment leveland can be used to compute and/or derive more complex instruments orpayment plans by combining groups of transactions. Payment plans torepay the loan can be adjusted at will by adjusting the group ofpurchases, transactions and/or payments to reflect changes to thepayment plan, payments made, changes to the service or productpurchased, or any other information.

In an embodiment, a merchant can use a line of javascript code to call ascript hosted by a credit service provider to execute a checkout system.The credit service provider can process the customer information and ifthe customer is approved for credit or pays for the transaction, thecredit service provider can issue a prepaid debit card number generatedby the credit service provider for the amount of the transaction and thedebit card number can be accepted by the backend payment software of themerchant without any modification. For example, if a merchant backendpayment system can accept debit or credit cards, the debit card numbergenerated by the credit service provider can be used with no change tothe existing backend payment processing system.

In an embodiment, calculations can be performed for each transaction tomake it easier for the consumer to understand the amounts and timing ofthe loan interest payments. The credit payments can be computed anddisplayed as a fee, instead of displayed as an interest rate ordisplayed as an interest rate, depending upon the customers' preferenceswhich can be selected through a preferences user interface. Customstatements can be created for each user. These custom user statementscan include for example: variable length statements of any date rangefrom entire account history to past month, past week, past 3 days orpast day. The groups of payments can be treated as individualtransactions with different due dates, and the fees can be independentlycomputed by the system. The payments and fees can be combined into acustom statement for a statement time period. This is substantiallydifferent than having the payments being lumped together for feecalculation and accounting computations which occur when using atraditional credit card. Also, in contrast to a traditional credit cardthat has a single balance, in an embodiment the inventive system canprovide the user with custom credit statements that can include multiplebalances financed at different interest rates, and/or different paymentperiods.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features of the invention are set forth with particularity inthe appended claims. A better understanding of the features andadvantages of the present invention will be obtained by reference to thefollowing detailed description that sets forth illustrative embodiments,in which the principles of the invention are utilized, and theaccompanying drawings of which:

FIG. 1 illustrates a block diagram of an embodiment of a system forfacilitating purchasing transactions.

FIG. 2 is a block diagram of a computer network system that implementsembodiments of a distance-based advertising delivery system.

FIG. 3 illustrates an embodiment of a user interface that includescredit and payment controls.

FIG. 4 illustrates an embodiment of a user interface with additionalsystem features including: dynamic down payment, custom payment,interest control and cancel credit.

FIG. 5 illustrates an embodiment of a user interface having dynamic downpayment controls.

FIG. 6 illustrates an embodiment of a user interface having customizablepayment controls.

FIG. 7 illustrates an embodiment of a user interface having interestpayment controls.

FIG. 6 illustrates an embodiment of a flowchart for using the system formaking a credit funded purchase.

FIG. 7 illustrates an alternative embodiment of a flowchart for usingthe system for making a credit funded purchase.

FIG. 8 illustrates an embodiment of a flowchart for using the system forproviding additional merchant offers to a credit funded purchaser.

FIG. 9 illustrates a bock diagram an embodiment of interactions betweena merchant and a credit service provider during a checkout process.

FIG. 9 illustrates an embodiment of a user interface for using thesystem for controlling the amount of customer requested credit.

FIG. 10 illustrates an embodiment of a user interface for using thesystem for Inputting user information.

FIG. 11 illustrates an embodiment of a user interface indicating creditapproval and credit terms.

FIG. 12 illustrates an embodiment of a flowchart for altering thepayment terms based upon an additional down payment.

FIGS. 13 and 14 illustrate an embodiment of a user interface thatincludes adjustable loan terms.

FIG. 15 illustrates an embodiment of a flowchart for altering thepayment terms based upon the user providing additional information.

FIG. 16 illustrates an embodiment of a user interface for inputtingadditional personal information for revised credit and loan terms.

FIG. 17 illustrates an embodiment of a user interface that includesadjustable loan terms based upon the revised credit and loan terms.

FIG. 18 illustrates an embodiment of a user interface with a loancontrol.

FIG. 19 illustrates an embodiment of a user interface with customerinput fields.

FIG. 20 illustrates an embodiment of a user interface with a creditrequest slide button.

FIG. 21 illustrates an embodiment of a user interface with creditverification and credit card inputs and purchase information.

FIG. 22 illustrates an embodiment of a user interface with a creditapproval message with a credit amount and repayment terms.

FIG. 23 illustrates an embodiment of a user interface with a creditrequest slide button.

FIG. 24 illustrates an embodiment of a user interface with customerinformation input fields.

FIG. 25 illustrates an embodiment of a user interface with a creditapproval message.

FIG. 26 illustrates an embodiment of a user interface for a purchasecheck out with a verification code input.

FIG. 27 illustrates an embodiment of a user interface with a creditapplication and payment message.

FIG. 28 illustrates an embodiment of a user interface shopping bag.

FIGS. 29, 30 and 31 illustrate flow charts showing sequences of stepsfor making credit based purchases using credit tools.

FIG. 32 illustrates a block diagram of an embodiment of a credit termprocessor accounting system for produce producing credit purchasestatements.

FIGS. 33-36 illustrate block diagrams of embodiments of credit termprocessor accounting systems used for current and past purchases.

FIG. 37 illustrates an embodiment of a purchase information statementproduced by a credit term processor accounting system.

FIGS. 38 illustrates a graphical representation of an embodiment of anembodiment of the credit term processor accounting system used toequalizing scheduled payments for purchases.

FIG. 39 illustrates a graphical representation of an embodiment of anembodiment of the credit term processor accounting system used to applyextra payments to reduce future scheduled payments.

DETAILED DESCRIPTION

The present invention is directed towards systems and methods forfacilitating purchasing transactions that can be used to providecustomized and flexible purchase and credit transaction terms. Incontrast to these traditional credit methods, the inventive system canprovide a wide range of payment terms that are substantially differentthan the traditional payment means. The inventive system can adapt to anindividual customer's unique cash flow situation to provide a loan thatbest fits the customer's ability to repay the loan.

Aspects of the one or more embodiments described herein may beimplemented on one or more computers executing software instructions.The computers may be networked in a client-server arrangement or similardistributed computer network. With reference to FIG. 1 , in anembodiment, the inventive system can include a system server 50, whichis used with a plurality of mobile devices 72. The system server maywork with other merchant and service provider servers 70 to processcommunications from the mobile devices 72. For example, in anembodiment, the system server 50 can provide a “white-label” for othermerchant servers/databases 70. The system server 50 may have a systemdatabase 52 for storing information about the users and the mobiledevices 72. The system server 50 can also communicate with othermerchant servers/databases 70 to obtain information and verifyinformation about the mobile devices 72 and the users of the mobiledevices 72. The server 50 is coupled, directly or indirectly, to one ormore merchant servers/databases 70 and a plurality of mobile devices 72through a network. The network interface between server 50, merchantservers/databases 70 and mobile devices 72 may include one or morerouters that serve to buffer and route the data transmitted between theserver and client computers. The network may be the Internet, a WideArea Network (WAN), a Local Area Network (LAN), or any combinationthereof.

In one embodiment with reference to FIG. 2 , the system server 104 is aWorld-Wide Web (WWW) server that stores data in the form of web pagesand transmits these pages as Hypertext Markup Language (HTML) files overthe Internet 110 to the client computer(s) 102, 118. For thisembodiment, the client computers 102, 118 typically runs a web browserprogram 114 to access the web pages served by system server 104 andmerchant servers 106 and merchant databases 122.

In one embodiment, a system server 104 in network system 100 is a serverthat executes financing for the purchase of goods and/or serviceprocessing on the client computers 102, 118. Server process 112 mayrepresent one or more executable programs modules that are stored withinnetwork server 104 and executed locally within the server.Alternatively, however, it may be stored on a remote storage orprocessing device coupled to server 104 or network 110 and accessed byserver 104 to be locally executed. In a further alternative embodiment,the sales process 112 may be implemented in a plurality of differentprogram modules, each of which may be executed by two or moredistributed server computers coupled to each other, or to network 110separately.

For an embodiment in which network 110 is the Internet, system server104 executes a web server process 116 to provide HTML documents,typically in the form of web pages, to client computers coupled to thenetwork. To access the HTML files provided by server 104, clientcomputer 102 executes a web browser process 114 that accesses web pagesavailable on server 104 and other Internet server sites, such assupplemental servers which may also be a network computer. The systemserver 104 can provide a “white-label” for other merchant servers 106that can sell goods or services to clients. Alternatively, in anembodiment, the system server 104 can provide financing to clients 102,118 that can be independent of transactions with the merchant servers106. The merchant servers 106 can be coupled to merchant databases 122that store merchant information. The client computer 102 may access theInternet 110 through an Internet Service Provider (ISP). Data for any ofthe customers, goods and services purchased, and merchants may be storedby a data store 120 that is closely or loosely coupled to any of theserver 104 and/or client 102.

The client computers 102, 118 may be a smart phone or another computingdevice such as a computer, personal digital assistant, or similarcomputing device that provides access to the Internet network 110 and asufficient degree of user input and processing capability to execute oraccess any required client-side application. More specifically, theclient computers 102, 118 include a processor, memory, input anddisplay. The client computers 102 and 118 may be coupled to the servercomputer 104 over a wired connection, a wireless connection or anycombination thereof. The client computer 118 can include a touch screendisplay which can function to display user interfaces with loaninformation and provide an input mechanism for load adjustments.

In addition to providing communications between the system components,the inventive system can also control and monitor the transfer of fundsbetween the financing service provider, merchants and client customers.For example, when customers use credit from the financing serviceprovider, the merchant can be paid directly by the financing serviceprovider by any means such as: electronic funds transfers, wiretransfers, checks, or any other payment methods. When customers repaythe financing used to make a purchase, the payments from the customerclients to the financing service provider can similarly be through:electronic funds transfers, wire transfers, checks, automated checkingpayments or any other payment methods.

The inventive systems and methods can be used in combination withpurchasing systems described in U.S. patent application Ser. No.14/573,334, “System and Method of Transacting” filed Dec. 17, 2014,which are hereby incorporated by reference in its entirety. Theinventive system and method is used for providing financial services forinstantaneous credit for financial transactions, which can includepurchasing goods or services. The “credit determination” can be apre-approval process for shopping at a merchant website or physicalstore, enabling the merchant to offer, or enabling a customer to ask forcredit before or during or after shopping. An offer for potential creditis presented to or accessed by the customer and the customer can “applyfor credit” using their phone number and/or other identifyinginformation, regardless of whether or not the customer has shopped witha merchant or the credit provider's payment system before. The creditprovider can take the user's identifying information, and/or themerchant information and/or the transaction information (e.g. itemsalready in cart, or items previously purchased) and can provide creditfor that customer to spend at that merchant. Credit determination can bebased upon customer information such as: FICO score, financial historysuch as bank/credit accounts, employment duration, job title, mobilephone information, and/or other available information. The customerinformation may be stored on credit provider databases. In anembodiment, the credit can be contingent upon specific products orservices and possibly further limited to specific products or saleitems.

The credit provider may require customers with extremely low estimatedcredit determinations to provide additional information such as a creditcard or bank account number before credit is offered. If the customeralready has a personal account with the credit provider, the customercan log into the credit provider's website to access the customer'sexisting account using the passwordless login system. In an embodiment,the system may store customer account information and may allowcustomers to access their account information through a passwordlesslogin system such as the system described in U.S. ProvisionalApplication No. 14//578,353, “System and Method For Passwordless Login”filed Dec. 20, 2014, which is hereby incorporated by reference in itsentirety.

When making a purchase, the system may interact with a mobile computer,such as a smart phone, and provide a graphical user interface thatallows instant credit repayment terms to be changed. For example, withreference to FIG. 3 , an example of a graphic user interface 100, thatincludes credit and payment controls, is illustrated. In this example, acredit of $200 is authorized for a customer. The user interface caninclude a credit amount slide button 103 that allows the customer tocontrol the amount of credit being accepted. In this example, the creditaccepted can range from a minimum value of $50 to a maximum value of$200. These values can be displayed with the credit amount slid button103 so that the user knows how to control the value amount. In otherembodiments, the minimum credit can be controlled by the minimumtransaction value allowed by the credit provider. Similarly, the maximumvalue can be determined by the maximum credit authorized by the creditprovider. In this example, because the user has elected to accept $150in credit, the system can display the value of $150 as the amount theuser would like to borrow.

In an embodiment, the system can also display a number of paymentsslider button 105 that allows the user to change the number of paymentsrequired to pay back the $150 credit. In this example, the paymentoptions may include any number of payments between 1 and 20. In thisexample, the user has selected 3 payments and the graphical userinterface 100 can display the text, “3 payments”. The system can changethe number of payments and calculate the value of the payments basedupon the selected number of payments. For example, if the user selects 1payment, the system can display, “1 payment of $150,” and if the userselects 10 payments, the system can display, “10 payments of” “$15”. Thenumber of payment months may increase as the number of payments sliderbutton 105 is moved from the left side to the right side of the display.In this example, the customer may not be charged any interest for thecredit because the repayment term is fairly short.

In an embodiment, the payment time interval can also be controlled bythe customer. In the illustrated example, the customer can also use apayment interval button 107 to select the payment interval. Although thepayments are shown as being monthly, in other embodiments the system canprovide any other payment time intervals such as: weekly, bi-monthly,every 2 months, each year, etc. In an embodiment, the default paymentinterval can be monthly, as shown. Since the customer has selectedmonths, the graphical user interface 100 displays the text “3 paymentsof $50/month.”

In other embodiments, interest can be integrated into the inventivesystem. The interest charged can be part of the system's paymentcalculation, and the interest rate can be displayed on the graphicaluser interface 100 to inform the customer. The interest being chargedcan be proportional to the amount of the loan and the duration of thepayments. For example, a lower interest rate can be charged for smallamount of credit and/or a shorter payment period and a higher interestrate can be charged for a larger amount of credit and/or a longerpayment period.

The system may automatically calculate and display the interest ratescharged based upon a financial algorithm. The system may charge a firstinterest rate for a first payment time period, a second interest ratefor a second payment time period, etc. For example, in a simple example,the interest can equal the payment time in years selected by thecustomer. Thus, the system interest algorithm may charge 1% interest forpayments completed in 1 year or 12 months, 1.5% interest for paymentscompleted in 1.5 years or 18 months, 2% for payments completed in 2years, 2.25% for payments completed within 2.25 years or 27 months, etc.In other embodiments, any other interest calculation can be applied.Thus, when the customer slides the payment slider buttons 103, 105, 107,the graphical user interface can display the total credit, the number ofpayments, the amount of each payment and the interest being charged.Once the credit and terms are set to the desired settings, the customercan click the continue button 221 to proceed with the credit acceptance.Although the user interface has been described as having sliding buttonsthat can control the terms of the credit payment, in other embodimentsany other input can be used including numeric input cells, pull downmenus, scroll wheels, etc. In addition to the described user interfacecontrols, the user interface 100 can also include an “Increase DownPayment” button 223 and a “Provide More Information” button 225 whichwill be described in more detail later.

The user interface 100 may also allow a customer to select otheroptions. The options button 111 can allow additional option controls tobe displayed. With reference to FIG. 4 , an options user interface 120is displayed with additional system features including: dynamic downpayment 121, custom payment 123, interest control 125 and cancel credit127. The customer can then select the dynamic down payment 121, custompayments 123 or interest control 125 buttons which can result in anadditional user interface being displayed, or select the cancel credit127 button which may result in a cancel confirmation page beforeallowing the customer to cancel the credit offer. With reference to FIG.5 , if the dynamic down payment option is selected, a dynamic downpayment user interface 130 will be displayed. In some situations, thecredit being offered to the customer may be insufficient to purchase adesired item. The basic principle of the dynamic down payment feature isto allow a customer to purchase goods or services that exceed themaximum credit being offered by providing funds to make up thedifference. The system can allow a customer to divide the payment withthe offered credit and the balance of the purchase being paid throughany other means. The combination of the credit and the other fundsprovides the necessary cumulative funds to complete the desiredpurchase. This can be particularly useful when a customer does notqualify for enough credit to purchase a desired item. This interface isoptional, as a credit provider or a merchant may restrict optionsavailable to a customer, or the customer may restrict the optionsavailable via their account preferences.

In the illustrated example, a customer wants buy a $500 item but themaximum credit offered is only $300, The customer can provide thebalance of the $200 at the time of purchase through other means, such ascredit cards, cash, check, etc. The user can control the amount neededslider button 133 to select the amount of money needed for the purchase.The system may know that the maximum credit being offered is $300, sothe amount being provided can only range from $200 to $500, which is theamount needed minus the maximum credit being offered. These andintermediate values can be displayed on the amount provided sliderbutton 135. The customer can then control the amount provided sliderbutton 135 to the amount of money that can be provided through othermeans. In this example, the customer has selected $200 as the amountbeing provided. The system can then display the accepted credit of $300and the user can select the desired payment terms with the number ofpayments button 137 and the payment intervals with the payment intervalbutton 139. In the illustrated example, the user has chosen 6 paymentsat monthly intervals. The system can determine that the payments will be$50/month at a 0% interest rate and display this information.

If the maximum determined credit is less than the amount requested, thecustomer can request to do a dynamic down payment where the customertakes some or all of the credit approved for their account and providesa down payment for the rest of the transaction. This dynamic downpayment can resemble a down payment on a larger purchase, and could bepresented as that kind of transaction to a customer. However on thebackend the dynamic down payment option is a combination of a paymentusing a different instrument and the use of a credit provider's creditto the customer's account to pay the merchant for the items in full.

The dynamic down payment option can solve a purchasing problem that canoccur with credit cards. For example, if a customer has $300 in cash anda credit card limit of $300 it can be difficult to purchase a $500 item.When the customer tries to buy the item with the credit card, the creditcard transaction will be declined and the customer does not have enoughcash to complete the purchase. Thus, the customer cannot complete thepurchase. The inventive system can prevent this problem by allowingpurchases to be made with a combination of offered credit and otherfunds or credit cards,

In an embodiment, the customer can select the custom payment option 123from the options user interface 120 illustrated in FIG. 4 , The systemcan respond by displaying a custom payment user interface 140 as shownin FIG. 6 . In this example, the user may be offered up to $400 incredit and the customer has selected $300 with the amount slider button141. The user can then select a number of payments with the number ofpayments slider button 143. In this example, the user has selected 3payments.

The system can then display date inputs 145 for the dates of the 3payments. The date inputs 145 can be pull down menus, scroll wheels, orany other suitable date input mechanism. In this example, the user hasselected a first payment of $100 on May 1, 2014, a second payment of$1.00 on Nov. 1, 2014 and a third payment of $100 on Dec. 1, 2014. Thecustomer can click on the continue button 142 to complete thistransaction or the options button 144 to return to the options page.

In sonic embodiments, a customer may be offered more credit or longerpayment terms if interest is paid on the credit It may be useful to thecustomer to know how much credit and the duration of payments that arepossible with the increased interest. If the customer selects theinterest control 125 button on the options user interface 120 shown inFIG. 4 , the system displays an interest control user interface 150shown in FIG. 7 . A customer can move the interest slider button 155 tothe desired interest rate. In this example, the customer has selected 5%interest. The system can respond by displaying the possible paymentduration from 1 to 5 years on the number of years button 156 and acredit value of $200 to $1,000 on the amount button 151. In thisexample, the customer has selected a $600 credit with the amount button151 and 5 years of payments with the years of payment button 156. Thecustomer can then select the number of payments with the number ofpayments button 153 and the payment interval with the payment intervalbutton 159. In this example, the system displays the payment terms as 5payments of $138.58 based upon a 5 year 5% interest. The system may alsodisplay the total interest payments, which are $92.90 in this example.By utilizing the interest control tool, a customer can select apersonalized purchasing option knowing the different interest options.

In an embodiment, if the customer selects a lower amount and paymentduration, the system may automatically reduce the interest to match theproper interest rates for the transaction. For example, if the userselects an interest rate of 5% and then inputs an amount of $200 andpayment of 1 year, the system may reduce the interest rate to a lowerrate, such as 1%, that corresponds to the credit and payment duration.Once the user has configured the payments to the desired interest andpayment schedule, the customer can click the continue button 152 toproceed with the purchase. Alternatively, the customer can press theoptions button 154 to return to the options page.

The credit tools can be implemented or initiated in various differentways. For example:

1) A customer can visit a merchant or services website possibly from areferral or advertisement offering credit to the user.

2) Customers can request credit. An individual customer and/or allcustomers that meet a threshold credit rating could be pre-approved fora specific/flat amount of credit. This pre-approval can be based upon aminimum transaction size, average transaction size, average transactionsize for time of day.

3) Alternatively, the merchant can request credit for the customers.Merchant credit requests for customers can happen when the customers aremid-way through a shopping session on a website, and trying to decidehow much they can buy. The customer may have pre-approval for purchasescurrently in cart. However, the merchant may wish to provide thecustomers with pre-approval for purchases in cart, plus an amount of anattempted upsell.

4) This can also happen during the payment process after the user haschosen their items and then chooses Affirm as their method of payment atcheckout.

The described credit tools can be utilized in various different possibleways during the purchasing process. Examples of different embodiments ofthe credit tool implementation are described. With reference to FIG. 8 ,a flow chart of a possible sequence for customer purchasing isillustrated. The system can initiate credit 161 and the system can setthe financial instrument terms that can include total credit, scheduledrepayment, interest, etc. 163. Examples of the setting of the financialinstrument were illustrated and described above with reference to FIGS.3-7 . If the customer rejects the financial instrument terms, the systemcan stop the credit process 165. If the customer accepts the terms, thesystem can collect information from the customer 167. The system may askthe customer for information including: name, phone number for mobilephone, email address, birthday and a portion of the social securitynumber. The system may also collect information from the merchant 169.The merchant information can include a description or identification ofthe goods and/or services being purchased and identification informationfor the merchant. The system can also collect information from thecredit provider 171.

In an embodiment, as shown in FIG. 9 , a merchant 771 can use a line ofjavascript code 772 to call a script hosted by a credit service provider773 to execute a checkout system. An embodiment of javascript code 772to call a script hosted by the credit service provider 773 is below.

CODE:

<script> var_affirm_config = {    public_api_key: “XXXXXXXXXXXXXXX”,   script:  ″https://cdn1-sandbox.affirm.com/js/v2/affirm.js″ };(function(l,g,m,e,a,f,b){var d,c=l[m]||{},h=document.createElement(f),n=document.getElementsByTagName(f)[0],k=function(a,b,c){return function( ){a[b]._.push([c,arguments])}};c[e]=k(c,e,″set″); d=c[e];c[a]={ };c[a]._=[ ];d._=[];c[a][b]=k(c,a,b);a=0; for(b=″set add save post open empty reset on offtrigger ready setProduct″.split(″ ″);a<b.length;a++)d[b[a]]=k(c,e,b[a]); a=0;for(b=[″get″,″token″,″url″,″items″];a<b.length;a++)d[b[a]] =function( ){}; h.async==10;h.src=g[f]; n.parentNode.insertBefore(h,n); delete g[f];d(g);l[m]=c})(window,_affirm_config,″affirm″,″checkout″,″ui″,″script″,″ready″);</script>

The Javascript code described above can create a credit checkout for amerchant 771 that collects user information, transaction information,and/or merchant information. The credit service provider 773 can processthe customer information (and/or the transaction information and/ormerchant information) and if the customer is approved for credit or paysfor the transaction, the credit service provider 773 can issue a prepaiddebit card number 775 that can be generated by the credit serviceprovider 773 for the exact amount of the transaction and the debit cardnumber 775 can be accepted by the backend payment software of themerchant 771 without any modification (e.g. if a merchant backendpayment system can accept debit or credit cards, the debit card number775 generated by the credit service provider 773 can be used with nochange to the existing backend payment processing system) and fullyclears payment for the transaction. The issued prepaid debit card number775 can be used either one time for a single transaction or for multipletransactions with the same merchant/vendor 771, and can include anexpiry period of minutes, hours, days, weeks, months or years,functioning similarly to a “card on file” yet without the need for aphysical card to be associated with the customer.

Once the system has the customer, merchant and credit providerinformation, the system can make a credit decision 173 for the setfinancial instrument terms 163. The credit decision can be based uponthe customer information which can include: a mobile telephone numberassociated with a client and a legal name of the client from the clientcomputer. Using this information, the system processor can obtain clientcredit risk information. A low credit risk client will be more likely toreceive a credit decision to offer credit while a high client will beless likely to receive a credit decision to offer credit. If the creditdecision is approved, the system can let the customer proceed to a checkout screen 177. If the customer approves the check out, the purchase iscomplete 181 and if the check out is cancelled, the purchase is stopped179.

If the system denies the credit, the system can collect more data fromthe customer and possibly adjust the financial instrument terms 175. Theadditional information can include additional identificationinformation, credit card information or other information that may alterthe credit decision 173. The adjustment of financial terms can includechanging of the total credit, payment duration, interest rate, or otherterms that can alter the credit decision 173. Once the added informationis gathered and the terms adjusted, the system can again display thefinancial instrument terms 163 and repeat the described process. Aftermore information and/or terms are adjusted, the credit decision 173 maybe more likely to be approved and the purchase is completed 181.

In the described embodiment, the financial terms are set at thebeginning of the purchasing transaction. However, in other embodiments,the described process for setting the financial terms can occur at anyother point during the purchasing transaction. With reference to FIG. 10, a flow chart of an alternative embodiment of the described creditprocess is illustrated. In this embodiment the credit can be initiated191 and the system can collect data from the customer 193, the merchant195, and the credit provider 197 as described above with reference toFIG. 6 . The system can then make a credit decision 199. If the creditis denied, the system can inform the customer that the credit has beendenied and the system can collect alternative payment or paymentinformation which can include credit card, bank account or other paymentinformation.

If the credit decision is approved, the system can make adjustments tothe financial terms based upon data collected from customers 203 such asnumber of payments and interval between payments, data collected frommerchants 205 such as credit being offered, and data collected fromcredit providers 207 such as interest rates. The financial instrumentterms can be set and displayed for customer approval 209. If the termsare accepted by the customer, the purchase can be completed 213 and ifthe terms are rejected by the customer, the credit offer can be stopped211 and the system can collect payment or obtain payment information201. With reference to FIG. 9 , the process of completing the purchasecan include the substep of issuing a prepaid debit card number 775 thatcan be generated by the credit service provider 773 for the exact amountof the transaction, such that the debit card number 775 can be acceptedby the backend payment software of the merchant 771 without anymodification (e.g. if a merchant backend payment system can accept debitor credit cards, the debit card number 775 generated by the creditservice provider 773 can be used with no change to the existing backendpayment processing system) and fully clears payment for the transaction.

If the determined credit is greater than the amount of credit requestedby the customer, the customer is granted at least the amount of credithe or she requested. The system can then offer more credit than thecustomer asked for or the customer can be offered an upsell to a largercredit limit, with a higher (or lower) interest rate. These additionaloffers can be used as an encouragement to spend more or be provided withupsells in an online or physical retail store.

An embodiment of an additional purchase offer flow chart is illustratedin FIG. 11 . In some embodiments, the system can detect that the offeredcredit is not being accepted. Based upon the quantity of the amount ofthe unused credit, the system can issue an additional offer based uponsome or all of the remaining credit. In the example, the system caninitiate credit 251 and collect data from the customer 253, the merchant255, and the credit provider 257. The system can then make a creditdecision 259. If the credit is denied, the system can collect payment orpayment information 261 from the customer. If the credit is approved andthe system detects that all of the available credit being offered wasnot accepted, the system can allow the merchant to offer the customer anupsell deal for some or all of the remaining available credit 263. Ifthe customer accepts the additional offer, the customer can continueshopping 265 and proceed with the purchase of additional goods and/orservices to the check out 267. If the customer rejects the additionalmerchant offer, the system can proceed directly to the check out 267. Atthe check out screen 267, the customer can cancel the purchase, whichwill stop the purchase 269, or approve the checkout and complete thepurchase 271. The process of completing the purchase 271 can include thesubstep of issuing a prepaid debit card number that can be generated bythe credit service provider for the exact amount of the transaction,such that the debit card number can be accepted by the backend paymentsoftware of the merchant without any modification (e.g. if a merchantbackend payment system can accept debit or credit cards, the debit cardnumber generated by the credit service provider can be used with nochange to the existing backend payment processing system.) and fullyclears payment for the transaction.

In other embodiments, the credit process can include a dynamic downpayment process can include additional features that provide moreflexibility when making purchases. For example, with reference to FIG.12 , a flowchart is illustrated that describes a process for alteringthe payment terms based upon the user providing an additional downpayment. The customer visits a merchant site and/or merchant applicationand places one or more items in the shopping cart. Once the desireditems are placed in the cart, the user can proceed to check out 351. Thesystem can approve the customer for some credit but the amount of creditapproval can be insufficient to pay for the items in the cart. The userinterface can respond by displaying down payment and interest rateoptions 353.

With reference to FIG. 13 an embodiment of a user interface 160 isillustrated that includes the loan terms based upon the initial customercredit approval. If the user decides to pay additional funds to the downpayment, the system can display a user interface that allows the downpayment amount or interest rate loan terms to be adjusted. In thisexample, the user has input a down payment of $400 (231) and an interestrate of 5% (233). The system can respond to these inputs by offering acredit approval for a $600 (235) loan amount on a $1,000 purchase. Theuser can also input loan payment terms. In the illustrated example, userhas selected a term of 5 years (237) with a total of 5 payments (238)that are paid on yearly intervals (239). If the user accepts these loanterms, the user can click on the “Continue” button 221 and the systemwill proceed to process the transaction. In an embodiment, the user maywant to improve the loan terms and the user can change the down paymentand/or interest rate.

The user can click on the “Increase Down payment” button 223 to increasethe down payment on the purchase. With reference to FIG. 12 , thecustomer can have the option of submitting an additional down paymentwhich may alter the credit amount and/or credit terms 355. Based uponthe additional down payment the system can adjust the credit terms 357.The system can then display the adjusted credit offer based upon the newdown payment information. In the illustrated example with reference toFIG. 14 , the user has increased the down payment amount from $400 to$600 (162). In response to the increased down payment, the system candisplay improved credit terms with a new interest rate of 3% (164). Thecredit amount has been changed to $400 (166). However, the repaymentterms have not changed. The repayment is over 5 years (170) in 5payments (168) with an interval between payments of one per year (169).

With reference to FIG. 12 , the user can then choose to select andapprove the down payment amount and credit terms 359. If the userselects and approves the down payment and credit terms, the user canproceed to the checkout and verification process 361. If the user doesnot select and approve the down payment and credit terms, the system cangive the customer another opportunity to submit additional down paymentfunds to improve the loan terms 355.

With reference to FIG. 15 , a flowchart similar to FIG. 12 isillustrated that describes a process for altering the payment termsbased upon the user providing additional information. In an embodiment,the processing described with reference to FIG. 15 can be combined withthe processing shown in FIG. 12 . However, for simplicity, FIG. 15 showshow the system processes additional information provided by the user tochange the loan terms by improve (increase) the credit amount. Thecustomer visits a merchant store and/or uses a merchant application. Thedesired item(s) are placed in the cart, the user can proceed to checkout 351. The system can approve the customer for a loan for a part ofthe total cost and the user interface can respond by displaying downpayment and interest rate options 353. In an example, the system canrespond by offering the user the same loan terms shown in FIG. 13 .

With reference to FIG. 15 , the customer can have the option ofsubmitting additional information which may alter the credit amountand/or credit terms 354. If the user decides to input additionalinformation, the user can click on the “provide more information” button(shown as 225 in FIGS. 13, 14 and 16 ) the system can respond bydisplaying a listing of possible personal information input buttons.With the additional information, the system can have the option ofsubmitting additional customer information which may alter the creditamount and/or credit terms 354. If additional information is input, thesystem can adjust the credit amount based upon the new information andthe user interface can display the revised credit amount and creditterms 356. The system can then display the credit offer based upon thenew down payment information if the user has submitted new information.The user can then choose to select and approve the down payment amountand credit terms 358. If the user selects and approves the down paymentand credit terms, the user can proceed to the checkout and verificationprocess 361. If the user does not select and approve the down paymentand credit terms, the system can give the customer another opportunityto submit additional down payment funds or personal information toimprove the loan terms.

With reference to FIG. 16 , the user interface can allow a user to inputadditional personal information which can result in a revised (improved)credit and loan term offer. Various types of additional information canbe used by the system to adjust the loan terms. In an embodiment, theuser interface may display buttons that allow different types ofinformation to be input. These buttons can include: Bank Account 182,Social Network Account 183, Home Phone Number 184, Credit Card Number185, Home Address 186, and Employer 187. When the user clicks on any ofthe personal information input buttons, the system can respond bydisplaying inputs for the personal information.

The information for the Bank Account 182, Home Phone Number 184 andCredit Card Number 185 can include an input space for the number. Theinformation inputs displayed when the Social Network Account button 183is actuated can include: the social network name, user name andpassword. In response to clicking the Home Address 186 button, thesystem can display inputs for the home address and in response toclicking the Employer 187 button, the system can display inputs for nameand address.

With this additional information, the system can identify more of theuser's credit information and further validate the identity of the userand the system can improve the terms of the loan offer.

With reference to FIG. 17 , the system has processed additionalinformation provided by the user and the system has determined that theadditional information improves the credit worthiness of the user. Thesystem user interface now displays improved loan terms. In this example,the down payment remains $400 (231) and the total purchase is still$1,000. However, the interest rate has been changed from 5% to 4% (232)and the credit amount has been changed to $600 (235). The system canalso allow the user to select the loan replayment terms. In thisexample, the user has maintained the 5 year (237) repayment duration butchanged the payments to 60 (234) payments made on a monthly basis (236).

The information provided by the user can be processed in various ways.For example, a valid bank account number that was established severalyears ago would be evidence that the user is a real person and canimprove the user's credit risk. In contrast, if a bank account number isinvalid or if the account number has been frozen, this can be evidencethat the user is not credit worthy and the system can increase theuser's credit risk. Similarly, a valid social network account that hasexisted for a reasonable duration of time with many postings and socialconnections is evidence that the user is a real person. In contrast, asocial network that has just been set up with no posts and noconnections can suggest that the user may have created a fictitiousaccount. The system can analyze the user's social network informationand make further credit worthiness calculations based upon the user'ssocial network information, such as similarities with other fake orautomatically created accounts.

If a user inputs a home phone number, the system can determine if thephone number is active and a possibly the home address. In anembodiment, the system can compare the identity of the homeowner withthe system user to determine if the system user is the homeowner.Similarly, if the system inputs the home address, the system may knowthe location of the home and possibly the purchase price and currentestimated value which can be interpreted as an asset of the user. Theuser information indicating user assets can provide evidence that theuser is credit worthy with improved credit terms.

The credit card can provide information about the user including:available credit limit, current balance, balance remaining, and possiblyadditional creditworthiness information, such as how long a user hasheld the credit card, how often they pay it off in full, how frequentlythey are paying, if they are late. Additionally, a known fraudulentcredit card number can be used to initiate a “honey-pot” that can beused to detect, deflect and/or counteract attempts at unauthorized useof information. In an embodiment, additional information is solicitedfrom a possible scammer, and additional fraudulent information iscollected and added to a blacklist of names, addresses, numbers, etc.via the honey-pot.

If the user inputs the employer information, the system may be able topredict the user's employment, job stability and possibly predict theuser's income. For example, if the user inputs an established businesssuch as Bank of America, this can be interpreted as being more jobsecurity and possibly higher credit worthiness than a user who isemployed by a self funded start up company. In an embodiment, acombination of information can be used to determine more about the user.For example, if the user has a technical background in computer sciencebased upon his education posted on the social network and the user worksfor a software company, it is probable that the user is a computerprogrammer. Based upon the profession, employment location and employer,the system may also estimate an income of the user. The system may usethe predicted income of a user as evidence of the user's creditworthiness of the user. In an embodiment, it is possible for the creditterms to be made worse based upon the additional information provided bythe user. However, if the initial interest rate terms are set highenough by default, then any amount of additional information cannormally improve the purchase terms for the user.

With reference to FIG. 18 an embodiment of a user interface isillustrated with a single amount slide button 273 that controls theamount of credit that the customer requests. In this example, thecustomer has selected the amount 275 of $250 and the system hasdisplayed the payment schedule 277 of 3 payments of $83.33/month. Ifthis amount and the payment terms are acceptable to the customer, the“Let's Go!” button 279 can be pressed.

With reference to FIG. 19 , the system can respond to the acceptancebutton by displaying an input for customer information. The customer caninput mobile phone number in the Mobile Number field 301, the first andlast name in the First and Last Name field 303, the email address in theEmail Address field 305, the customer's birthday in the Birthday field307 and some of the digits of the social security number in the Last 4of SSN filed 309. In other embodiments, more or less information can berequested by the system. Once the customer has inputted the requestedinformation, the customer can press the “Finish” button 311. The systemcan process the customer information and then issue an acceptance or arejection of the credit for the customer or possibly a request foradditional information from the customer.

With reference to FIG. 20 , an example of a credit approval message isillustrated with some additional information about the terms of thecredit. In this example, the system has issued a credit 313 of $250 for90 days. The customer is informed that he or she can shop for up to $250and pay no interest or fees regardless of how much the customer spends.The customer is also informed that a text message that includes averification code will be sent to the customer's cell phone. Thecustomer can respond to the credit approval by clicking on the “StartShopping!” button 315.

With reference to FIG. 21 , a checkout webpage that includes the creditverification code input field 317 is illustrated. The user has ashopping cart 319 that includes 1× brow kit, 1× lip balm and 1× eyelinergel. The order summary section 321 shows a subtotal of $68.00, a newcustomer discount of $10.00 and free shipping. The order total is$58.00. The seller website knows that the customer has received a creditof $250 and the customer can input the verification code that wasreceived by the customer's mobile phone into the credit verificationcode input field 317. Once the verification code is inputted, thecustomer can click on the “Verify” button 323. Alternatively, if thecustomer did not receive the verification code, the customer can clickon the “Resend Code” button 325 which can cause the verification code tobe resent to the customer's mobile phone.

With reference to FIG. 22 , the verification code input from a checkoutwebpage, such as the one illustrated in FIG. 21 , was correct and thesystem displays a message 327 saying that the customer is using $58 fromthe credit provider and indicating that the credit balance is $192. Thesystem may also clearly show a “PAY LATER” arrow 329 indicating that $58will be paid in 90 days and a “DUE NOW” arrow 331 indicating an ordertotal of $0.00.

With reference to FIG. 23 , another embodiment of a user interface 333with a credit request slide button is illustrated. In this embodiment,the user can click on an ad or promotion to initiate a credit inputwindow from the credit provider. In this example, the user has moved theslide button 335 to a credit of $150 and the system displays 3 paymentsof $50/month. The user can click on the continue button 336 to proceedwith accepting this $150 credit. With reference to FIG. 24 , after thecustomer has chosen the loan terms, the system can request customerinformation that can include one or more of: mobile phone number, emailaddress, birthdate and a portion of the social security number. Asillustrated in FIG. 24 these pieces of information have been supplied asindicated by check marks in fields 337, 339, 341 and 343. In otherembodiments, less or more customer information can be required by thesystem. The customer can then click the continue button 336 to proceedwith the credit processing. The system can accept or reject the creditoffer based upon the customer information. The acceptance or rejectionof the credit offer can occur in real time which can be less than a fewseconds. With reference to FIG. 25 , if the customer information resultsin a credit approval, the system can display a message 345 indicatingthat the customer's credit has been approved for $150 with a paymentplan of 3 payments of $50/month.

The customer can accept the credit offer by clicking on the “GoShopping” button 338. The system can respond to the customer approval ofthe credit offer by sending a credit verification code to the customer'smobile phone that is used by the system to verify the credit offer madeto the customer. The customer can go shopping through a merchant websiteand select one or more items to purchase. With reference to FIG. 26 , atthe check out page of the merchant website, the system can display aninput for the verification code 347. In an embodiment, the merchant cartor payment webpage can be embedded with the credit processor requestinterface as shown. The customer can enter the verification code in thedesignated input space and click on the verify button 348. Withreference to FIG. 27 , after the verification code is validated by thesystem, a message 349 indicating that the credit has been applied to thecustomer's cart is displayed. In this example, the verification codeinput by the customer was valid and a $150 loan was applied to thecheckout purchase(s). The system can also display the payment terms of$50 for 3 months and the purchase using the credit can be completed.After this message is displayed, the purchase transaction can becompleted normally. For example, the transaction can be completed by themerchant sending the customer a receipt by email or text message. If theverification code is incorrect the system can instruct the customer tore-input the verification code. The system server can detect “suspiciousactivity” if a user improperly inputs the verification code multipletimes and the system can cancel the credit offer. Suspicious activitycan include numerous incorrect verification code inputs, excessive timebetween receiving the verification code and inputting the verificationcode, etc.

With reference to FIG. 28 , another embodiment of a user interface. Inthis embodiment, the user would fill their cart on a shopping site andbe offered the option to pay with credit while checking out. In thisexample, the user's shopping cart has $23 item in it. When the userclicks on the button to check out and pay later with credit, the systemcan request customer information that can include: mobile phone number,email address, birthdate and a portion of the social security number. Asillustrated in FIG. 24 , these pieces of information have been suppliedas indicated by check marks in fields 337-343. In other embodiments,less or more customer information can be required by the system. Thecustomer can then click the continue button 336 to proceed with thecredit processing at which point with reference to FIG. 26 the systemcan display an input for the verification code 339 to verify the user'sidentity. With reference to FIG. 27 , after the verification code isvalidated by the system, the system can accept or reject the creditoffer based upon the customer information. With reference to FIG. 25 ,if the customer information results in a credit approval, the system candisplay a message 337 indicating that the customer's credit has beenapproved for $150 with a payment plan of 3 payments of $50/month. Thecustomer can accept the credit offer and complete their checkout byclicking on the “Go Shopping” button 338.

In different embodiments, various sequences of steps can be used tooffer and process the credit. With reference to FIGS. 29 and 30 , flowcharts showing sequences of steps for making credit based purchasesusing the described credit tools are illustrated. A customer can firstvisit a merchant site after a referral or advertisement offering thecustomer credit 501. Alternatively, the customer can first enterinformation on a merchant site 513. The customer may then bepre-approved for credit on the merchant's website 503. The customer canselect the credit terms and installment payment details 505. Thecustomer can then go through the checkout and credit verification codeprocessing 507 as described above. In an embodiment, the system canoffer the customer an option of applying some or all of the creditoffered to make a first payment to the purchase transaction 509. Thesystem can include a credit term processor accounting system 511 thatprocesses the terms of the purchasing transaction, which can includemultiple payment transactions, interest payments calculated as fees forone or more portions of a transaction. The credit term processoraccounting system 511 can also generate payment statements computeddaily and projected into the future. Because the system is highlyflexible and customizable, the customer may be able to configure apayment plan schedule or readjust the payment plan schedule to best fitthe needs of the customer.

With reference to FIG. 31 , a customer can be shopping on a merchantwebsite 601. The merchant can send the customer a notification that thecustomer has been pre-approved for credit on the merchant side or amerchant partner's website 603. The customer can then click on a button,or the notification, to set the terms and installment payments for theoffered credit 605. The customer can place items to be purchased in avirtual cart on the merchant's website and proceed through the checkoutand verification process 607 as described above. The system may give thecustomer the option to pay for some or all of a first payment of thescheduled transaction 609. The system can include a credit termprocessor accounting system 611 that can compute daily and/or projectedfuture payment statements and payment plan schedules that can best fitthe needs of the customer. Although the flowcharts illustrated in FIGS.29-31 illustrate a specific sequence of process steps, in otherembodiments, the steps can be performed any suitable sequence tocomplete the purchase transaction.

With reference to FIG. 32 , the credit term processor accounting systemcan produce statements 701 that can include credit purchase details anda chronological sequence of purchasing transaction payment due dates.The credit term processor accounting system can receive transaction datafor purchases to produce the statements 701. For example, an individualpurchase 703 can be described with information including: an accountnumber 705 134589 and an $ amount 707 of $50. The repayment terms canindicate that the customer has 3 payments 709 in equal amounts 711 andthe interest rate being charged 713 is 6% and the payment dates 715 are:1/22/2014, 2/22/2014 and 3/22/2014. The information for this individualpurchase from a Webstore 717 can be combined with additional purchaseinformation 719 for apartment rental in a cumulative report 721 thatlists the repayment details of all purchases 717, 719 illustrated inchronological order. Since rent does not include any fees or interest,the payments represent the monthly $1,200 payment due with no fees. Incontrast, the Webstore purchase payments for the dates are listed inTable 1 below and include interest fees:

TABLE 1 Date Payment Due Fee Jan. 22, 2014 $17.36 $0.51 Feb. 22, 2014$18.02 $1.19 Mar. 22, 2014 $18.78 $1.95

With reference to FIG. 33 , a graphical illustration of how the creditterm processor accounting system can be used to pay for current and pastpurchases. In a first example, a customer may make a purchase at acurrent time, Time to 801, and the customer may elect to pay for thepurchase immediately in a “Pay Now” transaction 803 with paymentclearing. Alternatively, the system can also be used to finance apurchase with credit in a “Finance it” transaction 805 with a paymentfor the purchase made in the future, Time t_(N) 807. The payments can bemade in the future 813 and scheduled based upon anticipated, predictedand/or scheduled financing payments with swipes inserted N days out. Inyet another embodiment, the customer may have made a past transaction815 which can be a posted transaction on a transaction statement. Thecustomer may use the credit term processor accounting system to set up apost-financing credit 817 to borrow credit against a past transactionwith future payments scheduled based upon anticipated, predicted and/orscheduled financing payments with swipes inserted N days out.

As discussed, the credit term processor accounting system can generateand process the financial payment schedules for multiple purchases in asingle combined statement. With reference to FIG. 34 , payment schedulesfor a first purchase 401 and a second purchase 403 are graphicallyillustrated. In this example, a first purchase 401, labeled “Purchase1,” can include three payments. The first payment 405 may be made at thetime of purchase and therefore may not include an interest payment. Asecond payment 407 can include a second interest amount 409 based uponthe second payment date and a third payment 411 can include a thirdinterest amount 413 based upon the third payment date. Purchase 2 (403)can include two payments that both include interest amounts 415, 417based upon the payment date of Purchase 1, Payment 2 (407) and Purchase1, Payment 3 (411). Because the third payment 411 is made after thesecond payment 407 more time has elapsed and therefore the interestcharged 413 on the third payments 411 is greater than the interestcharged 409 on the second payments 407. Similarly, because the secondpayment 421 is made after the first payment 419, more time has elapsedand therefore the interest charged 417 on the second payment 421 isgreater than the interest charged 415 on the first payment 419. Thecredit term processor accounting system can generate a combinedstatement 423 that includes both Purchase 1 (401) and Purchase 2 (403)with each of the payments and increased interest charged for each of thelater payments. As shown in FIGS. 33-35 , payments in the future willhave larger interest payments on their individual amounts of principal,if the individual amounts of principal are identical.

In another embodiment shown in FIG. 38 the inventive system can beconfigured to make the amounts of the payments equalized across allpayment periods for multiple purchases. In this embodiment the interestportion of the payment will be higher relative to the principal portionof the payment for earlier payments and the interest portion willdecrease as the principal is paid off with each payment. This process isillustrated graphically with a set of payments corresponding to purchase1 shown as row 451, and a set of payments corresponding to purchase 2shown as row 453 and a combined statement as row 455. The purchase 1 row451 illustrates 3 payments used to purchase a first item. The payment 1461 is made at the time of purchase and does not include any interest.In contrast the interest on payment 2 (463 ) is a significant portion ofthe entire payment 2. The interest in payment 3 (465) is a smallerpercentage of the total payment 3. Similarly, for purchase 2, theinterest on payment 1 (467) is a larger percentage of the total paymentthan the interest on payment 2 (469). The system can combine thesepurchases into a combined statement, and while each individual purchasecan be divided into equal payments 471, these payments 471 on thecombined statement can vary depending on the purchase size, number ofpayments and the creditworthiness of the parties involved in thetransaction.

In an embodiment, the system may be flexible enough to allow foradditional payments in addition to the scheduled payments to reduce theamount owed later on the purchases. With reference to FIG. 39 , thecombined statement 457 lists a plurality of payments 471 as shown inFIG. 38 . When Purchase 1 Payment 1 is repaid completely with somesurplus 460, the surplus payment can be applied to the Purchase 1Payment 3 (the final payment) and reduces the interest due on thispayment due to the lower principal carried in the 3rd payment period.Thus, in the combined statement 459 after the payment 460, the lastpayment 475 is reduced based upon the surplus payment from 460 and isnow lower than the rest of the payments 473.

The scheduled payments for Purchase 1 401 and Purchase 2 403 areillustrated in a graphical manner with the principle shown as solidblocks and the interest shown as blocks defined by dotted lines. Thevolumes of the principle and interest blocks can be proportional totheir dollar values. Thus, in this example since the principal valuesare all the same, the principal blocks are all the same size. Incontrast, the interest payments increase with time, so the interestblocks can increase in size with more elapsed time. Since there is nointerest with payment 1 of purchase 1 (405), there is no interest block.

With reference to FIG. 35 , the credit term processor accounting systemcan also produce modified reports that can instantaneously calculate thecost to pay off the “Purchase 1” and “Purchase 2” at the current or anyfuture date. In the illustrated example, the credit term processoraccounting system can calculated the cumulative cost of paying off thetotal purchase 901 at the time of purchase so that customer can usethese calculations to make an informed decision between paying off thepurchases at any give time with reduced interest or paying for “Purchase1” and “Purchase 2” according to the scheduled payment plan withinterest. In the illustrated example 901, the cumulative payments forPurchase 1 and Purchase 2 are listed without any interest payments ifthe customer can pay off the purchases at the time of the purchase.

In other embodiments, it may be desirable to make a larger thanscheduled payment but not payoff the entire balance. With reference toFIG. 36 , the credit term processor accounting system is configured tographically illustrate the reduction in a future scheduled purchase bypaying more than the scheduled payment. In this example, the customerhas made the Payment 1 for Purchase 1 (405) and also paid someadditional money 425, which will be credited to the last scheduledPayment 3 (411) for Purchase 1. In this embodiment, the Payment 1 (405)is illustrated with a box that matches the size and shape of thescheduled Purchase 1, Payment 1 (405) and the Surplus block 425 isadjacent to the payment block 405. The size of the payment and surplusboxes can be proportional to the dollar values of each. When the paymentand surplus are applied to the combined statement 423, the payment fillsthe scheduled Purchase 1 Payment 1 block 405. The surplus payment isapplied to the last scheduled Purchase 1 Payment 3 block 411 andgraphically illustrated by partially filling this block as well aspartially filling the Interest on Payment 3 block 413. If the surpluscompletely filled the Purchase 1, Payment 3 block 411, any remainingsurplus could be applied to the Purchase 2, Payment 2 block 421 and theinterest on Payment 2 block 417.

With reference to FIG. 37 , in an alternate embodiment, the credit termprocessor accounting system can produce statements 551 that can listpurchases and provide purchasing information that can include: purchasedate 553, merchant or payment recipient 555, transaction verificationcode 557 and the amount of credit paid or used 559. It can be desirableto graphically illustrate the payments made for specific purchases. Inthis example, the customer made a purchase of $4.90 from Brett's BeanieBabies 561 and a purchase of $12.92 from Alex's Air Drums 563. Thecumulative purchase is $17.82 and the statement also shows a Visapayment of $17.82 565. In order to show the relationship between thepurchases and the payment, the system can show a line and dots 567 torepresent the payment for these purchases. In other embodiments, anyother graphical mechanism can be used to illustrate this relationship.

The optimal choice for how to extend credit may vary by merchant, byproduct, by customers, by culture, by region or any other parameter.Optimal parameters can be configured by testing and customizationaccording to how customers respond to being granted different levels ofcredit at different points in the purchasing process. In an embodiment,the system may be able to measure customer trends. This data can be usedfor predicting future behavior. For example, are customers more likelyto spend more with more credit? However, are they also more likely tomiss payments to repay the higher credit? The system may also be able totrack whether the customer is only spending up to their budget, orwhether the customer is just spending more, and how the customer feelsabout having additional credit. Does the receipt of extended credit, orhaving more credit than credit cards result in a change in behavior?Again, these customer reactions can result in refinements to the system,which can have the desired result of providing additional funds tocustomers and increasing purchasing power.

The examples and illustrations included herein show, by way ofillustration and not of limitation, specific embodiments in which thesubject matter may be practiced. Other embodiments may be utilized andderived therefrom, such that structural and logical substitutions andchanges may be made without departing from the scope of this disclosure.As a person skilled in the art will recognize from the previous detaileddescription and from the figures, modifications and changes can be madeto the preferred embodiments of the invention without departing from thescope of this invention.

1-20. (canceled)
 21. A method for conducting a transaction between acustomer and a merchant by a financial provider, the method comprising:receiving, from a customer device, an indication of a request forfinancing to conduct the transaction; collecting customer data from thecustomer responsive to the indication of the request; collectingmerchant data from the merchant responsive to the indication of therequest; collecting financial provider data from the financial providerresponsive to the indication of the request; performing a creditdecision based on the customer data, the merchant data and the financialprovider data; and responsive to approval of the request, generating avalue card to support conducting the transaction and providinginformation associated with the value card to a merchant website tofacilitate completion of a checkout process to complete the transaction.22. The method of claim 21, wherein the collecting customer data isperformed in response to generating instructions for display offinancial terms and repayment information associated with a financialinstrument associated with the value card and receiving acceptance ofthe financial terms from the customer device.
 23. The method of claim21, wherein the collecting customer data is performed prior togenerating instructions for display of financial terms and repaymentinformation associated with a financial instrument associated with thevalue card and receiving acceptance of the financial terms from thecustomer device.
 24. The method of claim 21, wherein the generating thevalue card comprises generating a prepaid debit card number withexpiration date and card verification value (CVV) for provision to themerchant website.
 25. The method of claim 24, wherein the prepaid debitcard number is issued for an exact amount of the transaction.
 26. Themethod of claim 24, wherein the prepaid debit card number includes anexpiry period of minutes or hours.
 27. The method of claim 24, whereinthe prepaid debit card number includes an expiry period of days orweeks.
 28. The method of claim 24, wherein the prepaid debit card numberis stored at a database of the merchant for future use within apredetermined period of time.
 29. The method of claim 24, wherein theindication of the request is received via a website of the merchant andinitiates a javascript code to call a script hosted by the financialprovider to execute a checkout system via instructions for collectingthe merchant data and detailed information regarding the transaction.30. The method of claim 21, wherein the value card is a virtual debitcard.
 31. A server for conducting a transaction between a customer and amerchant by a financial provider, the server comprising processingcircuitry configured to: receive, from a customer device, an indicationof a request for financing to conduct the transaction; collect customerdata from the customer responsive to the indication of the request;collect merchant data from the merchant responsive to the indication ofthe request; collect financial provider data from the financial providerresponsive to the indication of the request; perform a credit decisionbased on the customer data, the merchant data and the financial providerdata; and responsive to approval of the request, generate a value cardto support conducting the transaction and provide information associatedwith the value card to a merchant website to facilitate completion of acheckout process to complete the transaction.
 32. The server of claim31, wherein the collecting customer data is performed in response togenerating instructions for display of financial terms and repaymentinformation associated with a financial instrument associated with thevalue card and receiving acceptance of the financial terms from thecustomer device.
 33. The server of claim 31, wherein the collectingcustomer data is performed prior to generating instructions for displayof financial terms and repayment information associated with a financialinstrument associated with the value card and receiving acceptance ofthe financial terms from the customer device.
 34. The server of claim31, wherein the generating the value card comprises generating a prepaiddebit card number with expiration date and card verification value (CVV)for provision to the merchant website.
 35. The server of claim 34,wherein the prepaid debit card number is issued for an exact amount ofthe transaction.
 36. The server of claim 34, wherein the prepaid debitcard number includes an expiry period of minutes or hours.
 37. Theserver of claim 34, wherein the prepaid debit card number includes anexpiry period of days or weeks.
 38. The server of claim 34, wherein theprepaid debit card number is stored at a database of the merchant forfuture use within a predetermined period of time.
 39. The server ofclaim 34, wherein the indication of the request is received via awebsite of the merchant and initiates a javascript code to call a scripthosted by the financial provider to execute a checkout system viainstructions for collecting the merchant data and detailed informationregarding the transaction.
 40. The server of claim 31, wherein the valuecard is a virtual debit card.